Large-scale, interactive websites are often built using a website building system. Such a website building system often handles the creation of the website, as well as its deployment. In such a scenario, the website building system provides the design environment, as well as the server infrastructure which serve pages to users of the website. Such website building and deployment systems typically provide end-user data creation and editing capabilities, allowing user generated content to be added to the website (as well as user generated content modification and deletion).
These capabilities may include multi-level user generated content support, e.g. allowing some users to design a blog creation site, some users to create new blogs, some users to add blog entries and some users only to add talkbacks to existing blog entries. The website building and deployment system may further enable different visual editing and design capabilities at each level.
Thus, there is no clear separation between designers and end-users. Furthermore, some users may be technically-savvy and familiar with the system (e.g. professional designers) and some may be more incidental and possibly non-technical users.
Many website building and deployment systems use an underlying internal database or repository to store the details of the websites, pages, components and related information. In such systems, the displayed pages are generated based on the underlying object structure of the website. Some website building and deployment systems can also provide additional database access capabilities (e.g. for data list capability, database integration, content management system integration and the like). Such database/content management systems may be internal to the website building and deployment system, or an external database/content management system accessed by the website building and deployment system.
Such a database/content management system can also be used to store some website components, specific user generated content elements or any other data. As per the example above, the website building and deployment system may store the blog definition in its internal repository, but store blog entries and blog talkbacks in two additional external databases.
In many systems, the deployed (published) websites have to stay up and running at all times—there is no way to shut down the website which may be mission-critical to the site owner's business. However, site development and maintenance may require website changes. Such changes to the website may require modifying multiple areas in the database—and thus “break” the website if published before being completed. Furthermore, such website changes must be tested before being made available to website users. Designers responsible for the modification often need the option to apply changes or discard them, and possibly the option to roll-back to a previous version of the website even after the changes have been applied to the running system.
In addition, multiple designers (or users) may be working on website changes which should be applied to the running system while resolving conflicts between these changes. This could be a single large change, or multiple separate (possibly multi-area) changes.
Some web site building and deployment systems support the integration of database information (also referred to as data lists). Such database information may be formatted, having a given structure defined by one or more database schemas. Changes to the website might require some of the schemas to be modified. However, the website should continue working while the schema has been changed. The schema change might be part of a larger change, so that additional website changes are required to make the entire combined change effective. Furthermore, as the website continues to work, designers and users (at various levels) might continue to add or modify data which is formatted according to previous schema versions.
The common solution is for the designers to use a separate copy or version of the website, known as the development version of the website. The changes are “released” to the publically available version of the site (known as production or public version of the site) only when finished and tested.
Furthermore, the designers may typically use a version control system to manage the elements of the web site being edited. Version control systems allow the designer to create branches of the managed elements set, to make changes, to commit changes, to discard changes and rollback to a previous version.